第一次認知到維運與開發思維會有落差的是因為快取機制，其實也不能說是有落差，應該是說有些面向是身為開發人員可能不會思考到的。

先來說明一下，什麼時候會使用到快取機制呢？當系統需要經常使用到某些資料，而這個資料的內容又不需要即時更新顯示時，開發人員可能就會把這些資料複寫出來，存放在另一個可以快速存取的儲存空間，當系統需要使用這些資料時，就可以直接從可以快速存取的儲存空間讀取複寫的資料，而不用直接到資料庫中讀取。

為什麼會想要建立快取機制呢？通常是當系統的使用人次變多了，如果頻繁地對資料庫拿資料，可能會對資料庫造成負擔，為了避免資料庫被操掛，這時候就會選擇使用快取機制。快取機制的使用，在稍有規模的系統中很常見，所以不論是開發或是維運人員都會知道也一定都能理解使用情境，既然都能理解，那兩方的認知差異是在哪兒呢？

讓我們試想一個情境，為了讓用戶能夠有良好的用戶體驗，所以我們準備了多個系統，放置在不同的地區，但不管用戶連到哪個地區，都可以正常的使用。在分流的前提下，我們會將用戶分群，A群用戶會預設連向A地區，B群用戶則會連往B地區，當使用者覺得連線品質不佳時或是某地區服務異常時，我們可以手動切換用戶連線的目標地區。

每當有用戶開啟系統時，都會需要取得連線區域的設定，正常情況下，區域連線的資料不會經常改動，但又經常會被使用，所以我們便將用戶與連線區域的設定放進了快取機制。採用的方式是當用戶開啟系統後，把連線資訊存入快取設備中，並且設定在快取中的資料在一定的時間過後會自動消失，後續用戶操作需要使用該資訊時，會先從快取中取得資料，如果快取中沒有資料，在連線至資料庫，讀取當下的資訊，再把資料重新從入快取。

快取機制中的資料每分鐘更新或是每五分鐘更新，對開發團隊來說影響不大，只要能達到保護系統的效果即可，但對於維運團隊在一線面對客戶時，就不一樣了，資料更新週期以及資料存放方式都會影響在第一線維運應對狀況。當需要調整連線地區的用戶數不多，去記憶每個用戶調整後生效時間再告知使用者重新嘗試連線，可能不會是一種困擾，但如果同時間要處理的用戶數到達一定的數量後，對維運人員就會一種負擔。

在實際接觸維運人員之前，都認為只要保護好系統，讓系統不要 crash 就好，但在與維運團隊討論時，有個印象深刻的回覆是：『當同時間要處理多則問題時，我哪裡還有時間去一個一個計時五分鐘，看看設定是否生效？』，這是我在 Ops 叢林中，第一次深刻的意識到，開發時要記得把維運團隊在第一線的處理情境考量進來，否則不良的系統設計，殘害的就是身在第一線的同胞（拭淚）。

此外，快取中資料更新的方式是整個群組更新或是單一會員更新，對維運團隊來說也是相對重要的，我還記得，當初維運人員想要釐清存放快取資料時，是按照用戶群組區分還是單一用戶資料存放時，開發團隊窗口給的回覆是：「反正就是五分鐘更新，調整後，等五分鐘就對了，有必要了解到那麼細嗎？」

但實際上是維運團隊還真的是需要了解這些設計細節，才可以在第一線處理問題時，採取較快/較正確的措施，而且也必須了解每個異動，對系統造成的效果為何？如果不清楚設計，以為異動資料後，就可以解決同一群組內所有用戶的問題，也真的這樣回覆用戶了，當用戶再次使用時，發現一樣的狀況，是不是就會對這家公司產生疑慮，可能會認為沒有認真處理問題，也有可能會覺得職員本身就對公司系統不熟悉，而產生負面觀感。

這些瑣碎的小細節都是在研發單位時，比較少留意到的細節，也是我第一次覺得，自己好像有點理解，好像有點開始接觸到何謂 DevOps 。